Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks

ABSTRACT

A converged network accessible by client terminals is provided. The converged network includes a wide area network, a local area network, and a gateway linked to the wide area and local area networks. The gateway integrates billing and authentication functions of the wide area and local area networks.

RELATED APPLICATIONS

The present application is based on and claims priority from U.S. Ser.No. 10/213,239, filed Aug. 6, 2002, which application was based on andclaimed priority to Ser. No. 60/310,563, filed on Aug. 7, 2001, and Ser.No. 60/323,570, filed on Sep. 20, 2001.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to wireless data networks and,more particularly, to a method and apparatus for converging billing andauthentication functions of local area networks (LANs) and wide areanetworks (WANs).

2. Description of Related Art

Multiple wireless data technologies are emerging in both the wide areaas well as the local area. In the wide area, cellular operators havealready deployed 2 G data technologies such as circuit switched data.Many operators are currently migrating their networks to higher-speed,packet-based 2.5 G technologies such as, e.g., GPRS (General PacketRadio Service) and 1XRTT. There is also an increasing deployment oflocal area 802.11b based networks in “hotspots” such as airports,convention centers, and even coffee shops. These hotspots are operatedeither by wireless Internet service providers (such as, e.g., Wayportand Boingo in the U.S. and Jippii in Finland) or by cellular operators(such as, e.g., Sonera in Finland and Telia in Sweden).

Wide area wireless data is typically accessed through 2.5 G smart phonesor personal digital assistants (PDAs) and computer laptops equipped witha 2.5 G network interface card. Many vendors now make GPRS cards in aPCMCIA form factor. Network providers support 2.5 G data by adding GPRSequipment such as SGSNs (Serving GPRS Service Node) and GGSNs (GatewayGPRS Service Node) to their core network and by making software upgradesto their existing 2 G radio infrastructure. Local area wireless data istypically accessed through a mobile client device such as laptop or aPDA equipped with an 802.11b network interface card. To provide access,wireless Internet service providers (WISPs) typically deploy “accesspoints”, which are 802.11b base stations. These access points areconnected to the Internet through typical IP devices such as routers andswitches.

These wide area and local area wireless technologies complement eachother on the basis of coverage, mobility, bit rate, and cost. Wide areatechnologies provide a much larger coverage area compared to local areatechnologies and are also designed to support seamless mobilitythroughout the wide area. Local area technologies such as 802.11bprovide bit rates up to 11 Mbps, which are much higher than the tens ofkbps offered by WAN technologies. While 802.11b cannot be used toprovide wide-area coverage, it is a cost-effective way to providelocalized high-speed data. The total cost of ownership for providinglocalized high bandwidth data access using 802.11 based technology istypically 5-10 times lower than 2.5 G based wide area deployments.Further, 802.11 technologies also provide an alternative way to providelocalized high-speed packet-based wireless data for operators who mightnot be migrating to 2.5 G for cost or spectrum reasons.

While both wireless LANs and WANs are currently being deployed, they areoperated independently as separate entities without any interactionbetween them. In particular, the WAN and LAN systems have different setsof authentication mechanisms, billing systems, user profile databases,network management systems, and service platforms.

Furthermore, LAN deployments often tend to be regionally operated, andeach regional provider offers different rates and maintains its ownbilling and authentication systems. Users accordingly have to maintainseparate accounts with various LAN and WAN operators. This leads tomultiple accounts, passwords, charges, and bills, which is generallyvery inconvenient and unmanageable for users.

A need accordingly exists for integrating the operation of local andwide area wireless networks, particularly their authentication andbilling functions.

BRIEF SUMMARY OF EMBODIMENTS OF THE INVENTION

In accordance with one or more embodiments of the invention, a method isprovided for managing usage of a local area network (LAN) by asubscriber of a wide area network (WAN). The method includes the stepsof: (a) detecting an attempt by a terminal operated by said subscriberto access said LAN; (b) authenticating the subscriber based onauthentication information received from the subscriber andcorresponding information of record at a WAN authentication system; (c)when the subscriber is authenticated, allowing the subscriber to accessthe LAN; and (d) transmitting information on subscriber usage of the LANto a WAN billing system for integrated billing of LAN and WAN usage.

In accordance with one or more embodiments of the invention, a method isprovided for managing usage of a local area network (LAN) by asubscriber of a wide area network (WAN). The method includes the stepsof: (a) receiving a request for authenticating a WAN subscriber desiringaccess to said LAN; (b) authenticating the subscriber based onauthentication information received from the subscriber andcorresponding information at a WAN authentication system; (c) receivinginformation on LAN usage by said subscriber; and (d) transmitting saidinformation on LAN usage to a WAN billing system for integrated billingof LAN and WAN usage by said subscriber.

In accordance with one or more embodiments of the invention, a convergednetwork accessible by wireless client devices is provided. The convergednetwork includes: a wide area network; a local area network; and agateway linked to said wide area and local area networks, said gatewayintegrating billing and authentication functions of said wide area andlocal area networks.

In accordance with one or more embodiments of the invention, a convergednetwork accessible by wireless client devices is provided. The convergednetwork includes: a wide area network (WAN); at least one local areanetwork (LAN); and a gateway linked to said WAN and said at least oneLAN, said gateway authenticating WAN subscribers desiring access to saidat least one LAN based on credentials of said subscriber within saidWAN, said gateway also collecting information on LAN usage by thesubscriber and converting said information to a format useable by abilling system of the WAN.

In accordance with one or more embodiments of the invention, a gatewayis provided for managing usage of a local area network (LAN) by asubscriber of a wide area network (WAN). The gateway includes: anauthentication module for authenticating a WAN subscriber desiringaccess to said LAN based on authentication information received from thesubscriber and corresponding information of record from a WANauthentication system; and an accounting module for collectinginformation on LAN usage by the subscriber and converting saidinformation to a format useable by a billing system of the WAN.

In accordance with one or more embodiments of the invention, a method isprovided for authenticating a subscriber of a wide area network (WAN)for use of a local area network (LAN). The method includes the steps of:receiving an authentication request from a LAN access controllerindicating that an attempt by the subscriber of the WAN to access theLAN has been made; querying the subscriber of the WAN for authenticationinformation; receiving the authentication information from thesubscriber of the WAN; determining whether the authenticationinformation from the subscriber of the WAN is valid; and providing anindication to the LAN access controller that the subscriber of the WANshould be permitted to use the LAN when the authentication informationfrom the subscriber of the WAN is valid.

In accordance with one or more embodiments of the invention, a method isprovided for allowing multiple wireless operators to provide integratedauthentication and billing services for respective subscribers withinone wireless LAN hotspot. The method includes: (a) modifying a hotspotauthentication server to support multiple operators by assigning aseparate network access identifier for each operator; (b) associating agateway of each operator with each respective network access identifier;and (c) forwarding authentication requests received by theauthentication server to appropriate gateways, depending on the operatorselected by the user, each selected gateway providing authentication andbilling for the selected user.

In accordance with one or more embodiments of the invention, a method isprovided for allowing multiple wireless operators to provide 802.11services within a shared hotspot. The method includes the steps of: (a)assigning one of the available channels from the 802.11 spectrum to eachoperator; (b) assigning a unique ESSID for each operator; (c) assigningthe selected ESSID to all the 802.11 access points managed by eachoperator; and (d) providing user software that selects the ESSID toassociate with, depending on the preferred network.

These and other features will become readily apparent from the followingdetailed description wherein embodiments of the invention are shown anddescribed by way of illustration of the best mode of the invention. Aswill be realized, the invention is capable of other and differentembodiments and its several details may be capable of modifications invarious respects, all without departing from the invention. Accordingly,the drawings and description are to be regarded as illustrative innature and not in a restrictive or limiting sense with the scope of theapplication being indicated in the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified diagram illustrating CBG operation for nonSIM-enabled terminals in accordance with some embodiments of theinvention.

FIG. 2 is a simplified diagram illustrating CBG authentication forSIM-enabled terminals in accordance with some embodiments of theinvention.

FIG. 3 is a simplified diagram illustrating CBG authentication using atwo-factor security scheme in accordance with some embodiments of theinvention.

FIG. 4 is a simplified diagram illustrating one possible CBG two-factorauthentication scheme in accordance with some embodiments of theinvention.

FIG. 5 is a simplified diagram illustrating another possible CBGtwo-factor authentication scheme in accordance with some embodiments ofthe invention.

FIG. 6 is a simplified diagram illustrating yet another possible CBGtwo-factor authentication scheme in accordance with some embodiments ofthe invention.

FIG. 7 is a simplified diagram illustrating yet another possible CBGtwo-factor authentication scheme in accordance with some embodiments ofthe invention.

FIG. 8 is a simplified diagram illustrating CBG integration with USSDservers in accordance with some embodiments of the invention.

FIG. 9 is a simplified block diagram illustrating a CBG authenticationarchitecture in accordance with some embodiments of the invention.

FIG. 10 is a simplified block diagram illustrating a CBG billingintegration system in accordance with some embodiments of the invention.

FIG. 11 is a simplified diagram illustrating a CBG integrated with aGPRS charging gateway in accordance with some embodiments of theinvention.

FIG. 12 is a simplified diagram illustrating security interfaces inaccordance with some embodiments of the invention.

FIG. 13 is a simplified diagram illustrating CBG support for multipleoperators at a hotspot in accordance with some embodiments of theinvention.

FIG. 14 is a simplified diagram illustrating a CBG Server in accordancewith some embodiments of the invention.

FIG. 15 is a simplified diagram illustrating a hotspot architectureusing a BBSM in accordance with some embodiments of the invention.

FIG. 16 is a simplified diagram illustrating a hotspot setting using awireless roaming arrangement and deploying an access controller in thenetwork in accordance with some embodiments of the invention.

FIG. 17 is a simplified diagram illustrating a hotspot configurationwith iPass system in accordance with some embodiments of the invention.

FIG. 18 is a simplified diagram illustrating kiosk-based Internet accessin accordance with some embodiments of the invention.

FIG. 19 is a simplified call flow diagram illustrating service signupusing an existing Internet access device in accordance with someembodiments of the invention.

FIG. 20 is a simplified call flow diagram illustrating service signupfrom BBSM-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 21 is a simplified call flow diagram illustrating service sign upfrom WISPR-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 22 is a simplified call flow diagram illustrating service signupfor iPass-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 23 is a simplified call flow diagram illustrating service signupfrom kiosk in accordance with some embodiments of the invention.

FIG. 24 is a simplified call flow diagram illustrating service signupwith a SIM-enabled NIC in accordance with some embodiments of theinvention.

FIG. 25 is a simplified call flow diagram illustrating service signupusing a phone and login in accordance with some embodiments of theinvention.

FIG. 26 is a simplified call flow diagram illustrating service signupfrom RADIUS-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 27 is a simplified call flow diagram illustrating service usagefrom a BBSM enabled hotspot in accordance with some embodiments of theinvention.

FIG. 28 is a simplified call flow diagram illustrating service usagefrom WISPR-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 29 is a simplified call flow diagram illustrating service usagefrom an iPass-enabled hotspot in accordance with some embodiments of theinvention.

FIG. 30 is a simplified call flow diagram illustrating service usagefrom kiosk in accordance with some embodiments of the invention.

FIG. 31 is a simplified diagram illustrating service usage withSIM-enabled NIC in accordance with some embodiments of the invention.

FIG. 32 is a simplified call flow diagram illustrating service usagefrom BBSM/router enabled hotspot in accordance with some embodiments ofthe invention.

FIG. 33 is a simplified call flow diagram illustrating service usagefrom iPass-enabled hotspot in accordance with some embodiments of theinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention is generally directed to a method and an apparatusfor integrating wireless WAN and IP LAN based systems, particularlytheir authentication and billing systems.

U.S. patent application Ser. No. 10/173,084 filed Jun. 17, 2002describes a method and apparatus for converging local area and wide areawireless data networks. Application Ser. No. 10/173,084 is expresslyincorporated in its entirety by reference herein.

One or more embodiments of the invention are directed to a ConvergedBilling/Authorization Gateway (CBG) that enables a wireless WAN operatorto provide LAN access service to its existing WAN subscribers with asingle bill and account. The CBG can integrate the authentication andbilling systems of wireless operators with authentication and billingmechanisms used in LAN networks. The WAN operator's backend systemstypically interface with a home location register (HLR) database, whilethe LAN mechanisms typically use protocols like RADIUS. The CBGintegrates these two systems such that a WAN subscriber can access LANservices using the subscriber's WAN identity, thus avoiding the need fora separate bill for LAN usage. Further, the WAN operator can offervalue-added services while leveraging its existing billing andauthentication infrastructure. The CBG can be a server component that ispreferably deployed close to the carrier's network and links into thecarrier's network.

Current Authentication and Billing Systems

Current WAN Authentication and Billing Systems

Cellular users or WAN subscribers are typically authenticated in the WANthrough the WAN operator's HLR, which contains user profile informationas well as authentication parameters.

Specifically, in the case of a GSM/GPRS (Global System for MobileCommunications/General Packet Radio Service) system, each user'sterminal has a SIM (Subscriber Identity Module), which containsauthentication information. Also, each terminal has a specific IMSI(International Mobile Subscriber Identity) number. At subscription signup, the SIM is programmed with a unique secret (Ki) and authenticationalgorithms A3/A8. Only the terminal SIM and the HLR know thisinformation. When the user wishes to use his cellular terminal, the HLRpresents an authentication challenge random number (RAND) to theterminal. The SIM computes a response using Ki and A3. The response(SRES) is sent to the HLR. If the response matches the expected responsecomputed by the HLR, the user is authenticated and allowed to access thesystem. CDMA (Code Division Multiple Access) systems use a similarkey-based authentication scheme, using an algorithm called CAVE. Theuser authentication information is embedded in the terminal, and thereis no separate SIM card as in the case of GSM.

Usage information is typically generated in the form of Call DetailRecords (CDR) by different network elements for voice usage as well asfor data use such as a WAP (Wireless Application Protocol) gateway.Mediation systems collect information from various network elements andpresent it to the billing systems that generate the final bill for thesubscriber. Most billing today is based on minutes of use. As new dataservices are being deployed, other billing metrics such as volume ofdata, application type, etc., are also being used. Emerging standardssuch as IPDR (IP data records standard as specified by the ipdr.orgconsortium) define the format for generating data records for IP usage.

Current LAN Authentication and Billing Systems

Authentication and billing in LANs is typically done through IPmechanisms such as RADIUS and DIAMETER. RADIUS is an IETF specificationand specifies a mechanism for authenticating a remote user into thenetwork through an attribute/value pair such as a login name and apassword. RADIUS also allows collection of accounting information, wherethe network access server sends accounting information to a RADIUSserver. The access server typically sends duration, number of packets,and other usage information to the RADIUS server. The billing systemthen generates a bill based on the appropriate fee policy.

DIAMETER is the next-generation authentication and billing protocol andextends RADIUS with additional attributes for authentication andbilling.

Billing and authentication schemes today are generally focused on eitherLAN users or on WAN users and do not allow combined LAN/WAN basedauthentication for LAN usage.

Some LAN based systems can allow a user to access the Internet frommultiple LANs using a single account and yet receive a single bill.These systems are traditionally referred to as clearinghouses andsettlement systems. The user maintains a single account with aclearinghouse such as, e.g., iPass, GRIC, or Excelan. The user accessesthe network from any LAN that is part of the partnership agreement withthe clearinghouse through this single account and receives a singlebill. However, this mechanism is restricted to LAN-based access only anddoes not couple with WAN systems.

Converged Billing/Authentication Gateway

A CBG in accordance with one or more embodiments of the invention allowswireless WAN operators to use their existing WAN authentication andbilling systems to provide services to LAN users.

Briefly, the CBG can allow a LAN user using wired as well as wirelessnetwork interface cards to get authenticated and billed against the WANoperator's WAN infrastructure. To achieve authentication integration,the CBG uses a combination of WAN and LAN based authentication schemes.To achieve billing integration, the CBG can generate real-time usageinformation for LAN access in a format that is compatible with the WANbilling systems. This enables the operator's mediation systems tocollect the usage information and combine it with other WAN usageinformation to generate a single bill, regardless of LAN or WAN access.

Authentication Integration

Authentication integration relates to integrating authenticationrequests between the LAN and the WAN. As previously described, LANauthentication typically uses protocols such as RADIUS and DIAMETER toauthentication users. Most of these schemes are based on alogin/password mechanism. WAN authentication in GPRS/GSM technology usesSIM cards to store and manage user identity data and authenticate theuser with the HLR.

In accordance with various embodiments of the invention, users canaccess the LAN/WAN from a variety of terminals with different features.By way of example, terminals can include laptops and PDAs (personaldigital assistants) and other mobile computing devices. These terminalscan have a PCMCIA slot that can be used to attach an 802.11 NIC. Also,many devices sold now have an integrated 802.11 network interface.

These terminals typically generally fall into two categories withrespect to SIM support. One category includes terminals lacking inherentSIM support. In this case, the authentication challenge is to integratethe LAN authentication into the SIM infrastructure. The second categoryof terminals includes terminals with SIM support. For instance, someusers may use a PCMCIA SIM reader to hold a SIM card. Alternatively somevendors may have SIM embedded into the NIC itself. This category istypically smaller than the first category of terminals. In this case,the authentication challenge is to leverage the SIM in the terminal toauthenticate with the SIM infrastructure.

The authentication scheme in accordance with the various embodimentsgenerally falls into three broad categories. The first category ofauthentication is designed for terminals without SIM support. Theauthentication mechanism can use the WAN database for service creation.Subsequently, the scheme uses a LAN-based login/password scheme forauthentication. This scheme can also use LAN-based authenticationprotocols such as 802.1x.

The second category of authentication is designed for terminals with SIMsupport. In this case, the SIM in the terminal is used to provideauthentication during service signup as well as service usage.

The third category of authentication is designed for terminals withoutSIM support. In this case, the SIM in a user's phone is used to providethe integration with the SIM infrastructure. The third category isparticularly advantageous because while it does not require the terminalto have SIM support, it still integrates tightly into the SIMinfrastructure by using the SIM on the user's phone to provideauthentication. This additional security measure enables the operator toauthenticate that the user logging in is also in possession of thephone. This additional level of authentication can also provide locationupdates for LAN users within the WAN network.

These authentication mechanisms are described in further detail belowfollowing a brief summary of general billing integration issues.

Billing Integration

LAN based billing systems use protocols such as RADIUS to collect usageinformation. WAN networks have a generally more sophisticated set ofbilling systems. Some embodiments of the present invention are directedto integrating the two systems by picking up the usage information fromthe LAN and converting it to a format that can be accepted by the WANbilling systems. The usage collection in accordance with variousembodiments can be accomplished in multiple ways, including e.g., usingthe following three approaches.

The first approach is to provide a client on the user's terminal thatcan collect usage information as the user uses the network andapplications. This information can be delivered to the CBG to convert tothe WAN format.

A second approach is to leverage the existing usage measurementinfrastructure within the LAN to collect the usage information. Forinstance, the routers or network access servers in the LAN typicallycollect accounting information such as duration and volume of usage.This information can be accessed and delivered to the WAN systems by theCBG.

A third approach is to deploy additional monitoring equipment at thehotspot location to collect usage information. This can, e.g., be alayer 3-7 device that parses user traffic to collect usage information.This device may be deployed as an active or a passive device.

For instance, the monitoring equipment could be placed in the directpath of the connection between the client and the Internet.Alternatively, it could be tapped off of the connection through a hub.This device can be designed to collect information for usage, duration,as well as look at layer 7 headers to determine more details about theapplication usage.

An advantage of the first approach is that it does not require anyinterfacing with the LAN equipment directly. Also, application-levelinformation can be collected as well by parsing packets going in and outof the network interface.

An advantage of the second approach is that it does not require clientsupport and hence alleviates any privacy concerns.

One advantage of the third approach is that it can allow a much moredetailed level of information collection.

The billing integration approaches are described in greater detailfurther below. Note that in some of the call flows described in theauthentication description, a potential step of downloading a client onthe user's terminal is discussed. Note that this step is optional andonly needed if a client-based approach is selected.

Authentication Integration Mechanisms

The following is a discussion of three primary authenticationintegration approaches in the CBG. The three approaches are discussedfirst followed by a description of operational flow.

Dual LAN/WAN Authentication for Non-SIM Terminals

The first mechanism in accordance with some embodiments is to use theWAN authentication infrastructure to authenticate the user at servicesignup. Specifically, the user's information in the WAN/HLR is verifiedbefore the user is allowed to create a service. Once the user isauthenticated, a LAN-based login/password is created by the CBG. Thelogin can be, e.g., the user's cell phone number. For subsequent serviceusage, the CBG uses LAN based authentication mechanisms to authenticatethe user. This dual-mode authentication scheme allows a WAN subscriberto access LANs through LAN-based login/password style authenticationwhile still coupling with the operator's backend authentication systems.

This architecture has several advantages. First, by using the HLR forservice sign up only, it limits the number of accesses to the HLR. Sincewireless operators are typically very sensitive to usage of their HLRs,this architecture reduces the load on the HLR. Further, by restrictingthe use of the HLR, it limits the load on the HLR. Also, it does notplace any special requirements on the terminals that can be supported.

To address possible security limitations of the login/passwordauthentication, a recent development on the wireless LAN security fronthas been to use 802.1X for authentication. 802.1x is a port-basedsecurity protocol proposed by the IEEE 802.1x allows blocking of allaccess until the user is authenticated.

Support for 802.1x ordinarily requires changes in the terminals as wellas in access points APs. Specifically, the APs should be upgraded toblock all user traffic until authenticated. Most major vendors are nowupgrading their Aps to support 802.1X. On the terminal side, the driversshould be upgraded to send authentication information. The new WindowsXP operating system has inherent 802.1x support built into it. 802.1xuses RADIUS as the method to transfer authentication information betweenthe AP and the RADIUS server and the actual authentication messages aretransferred through a protocol called EAP. Using EAP, the actualauthentication can be accomplished through a number of standardprotocols, such as TLS, TTLS, SRP, etc.

The CBG also supports 802.1x authentication. The RADIUS server in theCBG should be modified to support EAP parsing.

WAN-Based Authentication for SIM-Enabled Terminals

The CBG in accordance with some embodiments also supports pure WAN-basedauthentication mechanisms for LAN access when the user's terminal hasSIM support. This may be the case if the laptop or PDA has a SIM reader.Another possibility is the case where the user has a special networkinterface card that has a SIM support. Nokia, e.g., makes such awireless LAN NIC. In this scheme, the CBG uses the HLR to authenticatethe user during service sign up as well as during real-time serviceusage. Specifically, the user's WAN device is used to provideauthentication even in the LAN. This is accomplished through the SIMcard, which is used for authentication in the GSM/GPRS network. In thiscase, the SIM is queried to give the authentication information evenduring LAN usage. This authentication scheme is similar to how mobiledevices are authenticated in the GSM/GPRS network today.

It is possible to also create a login/password in this case. This isuseful to authenticate the user in case he does not have access to theSIM at some point. This part of the approach would be similar to thefirst approach.

An advantage of this scheme is that the user's existing SIM is used forauthentication. It is as secure as the GSM/GPRS authentication.

Two-Factor Authentication for Non-SIM Terminals

A third possible authentication mechanism in accordance with someembodiments uses a combination of LAN and WAN based authentication forboth service signup as well as for service usage. Specifically, in thisscheme, a two-factor strong authentication mechanism is provided tosecure access for terminals without inherent SIM support. In thismethod, a login/password is used to authenticate users initially. Thisinterfaces with the existing LAN based authentication mechanism. Inaddition, the user's phone is used as a secure token to furtherauthenticate that the user signing in from the computer indeed haspossession of the phone as well. This additional level of security isneeded when the user information (such as location) is to be updatedwithin the HLR.

To address this further, note that a number of WAN services such as SMSmessaging and location-aware services require that the user's locationbe updated in the HLR. Since the HLR is a core element in the operator'sinfrastructure, the operator typically recommends that the user beauthenticated with great security before updating location. This thirdauthentication mechanism allows a higher degree of authentication thanthe first authentication mechanism described above. This approach henceallows users with terminals without SIM cards to be authenticatedagainst the operator HLR by leveraging the phone. As a result, locationupdates are possible for LAN based users. An advantage of this approachis that it provides a strong authentication mechanism. By ensuring thatthe user has the phone, a token-based identification can be provided.This mechanism may alleviate the operators' concerns in providing secureaccess to other services. This scheme uses the terminal and the phone,and it does not place any special requirements on the terminal. Further,in cases where the user may not have his phone or there may not becoverage, the CBG can use the login/password to provide a baselineauthentication that provides access to at least basic services ifdesired.

These three authentication mechanisms are described in greater detailbelow. In all these cases, the CBG preferably integrates usageinformation with the operator's billing system to produce a single billfor the subscriber.

Other possible authentication schemes are also possible, including thefollowing. First, for non-SIM enabled terminals, a “software” SIM can beplaced on the user's terminal. This would store on the user's terminal,some of the authentication information that is typically stored on theSIM module. In this case, the SIM authentication is emulated through a“virtual” SIM on the user terminal.

An alternative to this approach is to maintain the user's SIMinformation in a server within the network. In this approach, the usercan login through a login/password and authenticate with the networkserver. The server then communicates with the HLR by emulating the userterminal by using the SIM information stored at the server. Thisapproach eliminates some of the security risks by putting SIMinformation within the server.

The CBG can include two components: (a) a CBG server and (b) a CBGclient. The CBG server is installed in the operator's network andinterfaces with the operator's billing and authentication systems. TheCBG client is optional, and needed when the user has a SIM-enabledterminal and the SIM has to be accessed to send authenticationinformation. The client may also optionally be used to collect andtransmit usage information.

CBG Authentication Operation Flow

An example of CBG operation for Dual WAN/LAN based authentication fornon-SIM terminals is now described. FIG. 1 shows the operation of theCBG for the dual-mode authentication scheme, when the subscriber has aregular LAN card without any SIM features. In this case, theauthentication uses a combination of WAN and IP based authenticationschemes. When the user first subscribes for service, the CBG queries theoperator's customer databases (HLR) to validate the user's identity,similar to how the WAN operator checks identity before creating newservices today (e.g., check social security, address, data of birth, orother personal information). After the user is validated, the CBG 10instructs the user to create a login and password. The login can be,e.g., the user's cell phone ID for convenience. This information isstored in the subscriber database. This can be either part of the CBG orcan be maintained by the operator. For subsequent use, the CBG uses thislogin/password for authentication. Other operator-specific policies maybe stored in the CBG database as well.

The CBG server periodically validates the user information in the CBGdatabase 14 with the operator's customer databases 12 in order to keepthe services and users current. This is done off-line and is notrequired during service usage. The frequency of update can be tuned,based on the operator's policies as desired.

One possible method for service signup flow is as follows:

1. User goes to operator's web site to sign up for wireless LAN serviceusing terminal 16. Alternatively, the user can call up a servicerepresentative to sign up for service.

2. Operator queries if user has a SIM enabled terminal.

3. If not, user is queried for phone number. (The method for SIM enabledterminal is described later in this document.)

4. The phone number is sent encrypted to CBG server 10.

5. The CBG server 10 determines the IMSI associated with this phonenumber and gets the user's records for this IMSI from operator customerdatabases.

6. The CBG server 10 authenticates the user by some other informationsimilar to methods used to modify existing services (e.g., address,social security number or other information).

7. The CBG server 10 asks user to create a password.

8. The password is sent encrypted by the user (e.g., through SSL 128 bitencryption).

9. The CBG server 10 stores password and IMSI number pair in its localCBG database. Future authentication is performed through thislogin/password combination. At this time a client is optionallydownloaded on the user terminal.

To use the service:

1. The user goes to a WLAN hotspot.

2. The Access server at the hotspot (e.g., router) blocks traffic fromthe user terminal.

3. The Access server at hotspot communicates with CBG server forauthentication through RADIUS style protocol.

4. The CBG server queries the user for login/password information.

5. This information is sent encrypted to the CBG server by the CBGclient.

6. The CBG server authenticates the user against its database andinforms the router at the hotspot to authorize traffic for the client.

An example of CBG operation with dual LAN/WAN authentication using802.1x is now described. The service signup flow under this approach isas follows:

1. The user goes to operator's web site to sign up for wireless LANservice.

2. The operator queries if the user has a SIM enabled terminal.

3. If not, the user is queried for phone number.

4. The phone number is sent encrypted to the CBG server.

5. The CBG server determines the IMSI associated with this phone numberand gets user's records for this IMSI from operator customer databases.

6. The CBG server authenticates the user by some other informationsimilar to methods used to modify existing services (e.g., usingaddress, social security number, or other information).

7. The CBG server asks the user to create a password.

8. The password is sent encrypted by the user (through, e.g., SSL 128bit encryption).

9. The CBG server stores the password and IMSI number pair in its localCBG database. Future authentication is performed through thislogin/password combination.

10. If the user terminal does not have 802.1x support, the operatordownloads the 802.1x client on the user terminal.

11. Alternatively, in some specific 802.1x based cases, certificates areused for authentication. In this case, the operator can either assign auser certificate or verify the certificate before authentication.

To use the service:

1. The user goes to a wireless LAN hotspot.

2. The 802.1x-enabled 802.11 access point blocks activity when theuser's NIC tries to access the network.

3. The driver on the user terminal 16 exchanges authenticationinformation with the access point. The authentication depends on theprotocol involved. For example, in the case of a TLS (RFC 2246)authentication, the user is authenticated through a certificate. In thecase of TTLS (draft-ietf-pppext-eap-ttls-01.txt) authentication, theuser is authenticated through a login/password sent over EAP (RFC2284).

4. The CBG server 10 authenticates the user against its database 14 andinforms the access point at the hotspot to authorize traffic for theclient.

Other than the fact that the authentication information is sent throughEAP, this operation is similar to the basic RADIUS based authentication.

An example of CBG operation with WAN-based authentication forSIM-enabled terminals is now described.

As previously mentioned, WAN subscribers are typically authenticatedthrough a combination of the phone number, secret keys, andauthentication algorithms shared between the terminal and the HLR.Specifically, in the case of GSM/GPRS networks, the terminal informationis stored in a SIM card. The SIM card is typically used to authenticateWAN subscribers in the GSM network. When the WAN subscriber goes to theLAN, it would be desirable to use the same SIM for LAN authentication aswell. Some vendors (e.g., Nokia) provide SIM cards that can be removedfrom the cell phone and attached to a LAN card such as an 802.11 NIC. Inthis case, the LAN card has an associated SIM reader that can be used toquery the SIM for authentication information. FIG. 2 illustrates at ahigh-level the operation of the CBG system when authenticatingsubscribers that have a SIM enabled terminal 20. In this case it isassumed that the SIM card is attached to a LAN terminal 20 and that theSIM can be queried to get authentication information.

One approach for service signup flow can use the basic GSMauthentication mechanisms as follows:

1. The user goes to WAN operator's web site to sign up for wireless LANservice.

2. The operator downloads small client on terminal 20. (This client isresponsible for sending authentication from the SIM.)

3. The user enters his phone number on web site (e.g., sent through 128bit SSL encryption).

4. The web site communicates with CBG server 10.

5. The CBG server 10 contacts HLR 12 to get authentication informationfor the IMSI number associated with the user phone number.

6. The HLR 12 responds with an {IMSI, [RAND, SRES]} vector, where RANDis a challenge and SRES is expected response to challenge.

7. The CBG server 10 sends the RAND to terminal 20.

8. The CBG client on terminal 20 sends this information to the SIM.

9. The SIM computes the SRES and informs the client.

10. The CBG client sends the SRES to CBG server 10.

11. The CBG server 10 compares the SRES received with the value from HLR12.

12. If it matches, the user's terminal 20 is validated for service.

The {RAND, SRES} exchange is part of the standard GSM authenticationmechanism and is defined by the GSM standard.

To use the service:

1. The user goes to a WLAN hotspot.

2. The access server/router at hotspot blocks activity until the user isvalidated.

3. The Hotspot forwards an authentication request to the CBG server 10through a RADIUS style protocol.

4. The CBG server 10 queries the user terminal 20 for authenticationinformation.

5. The user enters phone number information.

6. The CBG server 10 validates the terminal through thechallenge/response scheme described in steps 5-11 in the signup phasedescribed above. The SIM client sends its response.

7. The CBG 10 informs router at the hotspot to authorize traffic forclient if there is a match.

Note that in this case, the user can also create a login/password inaddition to the SIM authentication. This would be similar to the firstcase described earlier. This will allow the user to login even when hisSIM may not be available. If desired, this can provide access to limitedservices only.

In addition to the two cases of SIM-based terminals described above,another possibility for the use of the SIM based approach is as follows.The user's terminal is a laptop with two network interface slots. Oneslot can contain a LAN interface card (e.g., 802.11b NIC) and the othercan contain a WAN interface card (e.g., GPRS or a CDMA NIC). The WAN NICis designed typically to authenticate itself with the WAN networkthrough the embedded keys and encryption algorithms. Thechallenge/response is typically communicated over the air interface.However, if the WAN NIC has an interface that allows the challenge to beprovided through a software interface, then the same NIC can be used forauthenticating the LAN user as well. Specifically, the CBG would sendthe challenge to the client on the terminal. This client in turn passesthe challenge to the WAN NIC. The WAN NIC computes the response, theresponse is read by the CBG client, and is communicated to the CBGserver. The CBG server matches the received response with the expectedresponse obtained from the HLR. If the two match, the LAN user isauthenticated.

The SIM-enabled 802.11 NIC example described earlier is a specificinstance of this scenario, where the CBG client can interface with theSIM through a SIM reader embedded in the NIC.

For the sake of simplicity, further description of WAN-basedauthentication involves the case where the SIM is connected to a NICwith a SIM reader. However, as would be understood by those skilled inthe art, the same mechanism can apply to other WAN-schemes as well.

An example of CBG operation with two-factor secure token authenticationis described with reference to FIG. 3.

As mentioned earlier, this approach uses a two-factor authenticationscheme, which uses a combination of a shared secret (login/password) andthe SIM on a user's phone 30. Briefly, the user first logs in through alogin and password. This login/password is stored in the CBG localdatabase 14. This mechanism integrates with the existing RADIUS serversat a hotspot location. Subsequently, the authentication system validatesthe user with an additional secret token using the user's phone 30.There are several possible mechanisms for accomplishing this.

An example service signup flow is as follows.

1. The user goes to operator's web site to sign up for wireless LANservice.

2. The user enters phone number on the web site (sent, e.g., through 128b SSL encryption).

3. The web site communicates with the CBG server 10.

4. The CBG server 10 contacts the operator databases to validate theuser through other information.

5. The user creates an account with the CBG 10 where the login is thephone number.

6. The CBG 10 sends an additional secret token to the user's phone 30.

7. The user returns this token to the CBG 10 by entering it on thelaptop or other terminal 32.

8. The CBG 10 validates that the user is in possession of the phone 30and creates account for user.

To use the service:

1. The user goes to a WLAN hotspot.

2. The access server/router at the hotspot blocks activity until theuser is validated.

3. The hotspot forwards an authentication request to the CBG server 10through a RADIUS type protocol.

4. The CBG server 10 verifies the user's login/password.

5. The CBG 10 sends an additional secret token to the user's phone 30.There are several ways in which secret tokens can be delivered to users.Examples of these are described in further detail below.

6. The user returns the secret.

7. The CBG 10 validates that the user is in possession of the phone 30and allows the user to start using the service.

Various methods are possible to use the phone for additional validation.

One example involves a GSM delivered password. In this scheme, the CBGgenerates a unique one-time session password. This password is sent tothe user's phone 30 through an SMS (short message service) or a USSD(Unstructured Supplementary Services Data) message. The user reads thispassword from the phone and types it onto the laptop 32 through a webpage interface provided by the CBG 10. The CBG 10 receives the passwordand compares it with what was sent to the phone. The match ensures thatthe user who logged in using a certain phone number as the login, isalso in possession of the phone. There is a typical latency of a fewseconds before this closed loop control is finished, since it takes timefor the SMS to be delivered to the user's phone 30. This is summarizedlogically in FIG. 4. Note that the random password used can either begenerated in the CBG itself or it could be obtained from the HLR. It ispossible, e.g., to use the RAND number provided by the HLR for SIMauthentication as the seed to generate this password.

One advantage of this scheme is that it supports all terminal typessince all phones support incoming or mobile terminated SMS. There isalso ease of use for users who just type in a password from the phoneinto a laptop.

Another possible scheme involves an IP delivered password as illustratedin FIG. 5. In this scheme, the CBG 10 generates a unique one-timesession password and delivers it to the user's terminal 32 as an IPmessage over the web interface. The user types in this password on thephone 30 and sends it to the CBG 10 as a mobile originated SMS or as aUSSD message.

In the case of an SMS message, the message is sent to the CBG ID. In thecase of a USSD message, the user presses a few identifying keys followedby a password, e.g., #112*password*#, where 112 is the service type thatis created specifically for the CBG. Note that to support the USSD, theCBG connects to the USSD servers in the WAN network. The USSD serverreceives the USSD message, which is identified by the special codes. Itrecognizes that the message is for the CBG through the special code anddelivers it to the CBG along with the IMSI of the phone from which thismessage is sent. The CBG receives this information from the USSD serverand validates that the received response matches what was sent out. Thisvalidates the user.

One advantage to using the USSD to deliver the password is that the USSDcan work with roaming users since it communicates with the HLR. Inaddition, the USSD is supported on all phones and requires a simplesequence of keys to be pressed. A third possible approach involves usingthe SIM as token generator as illustrated, e.g., in FIG. 6. In thisapproach, the SIM on the phone 30 is used to generate a secure token.The CBG 10 generates a unique per-session key and delivers it to theuser's terminal 32. The phone 30 is equipped with a special CBGapplication developed using the SIM API toolkit. Specifically, thisapplication is designed to respond to some keystrokes from the phone. Inthis case, the user enters a sequence on the phone 30 and passes thetoken received from the CBG 10. The SIM application, in turn, processesthis token and generates a key. This response can be conveyed to the CBG10 in one of two ways. One option is to display the response on thephone 30 so that the user reads it and types it back on the terminal 32to send to the CBG over IP. The other alternative is for the SIMapplication itself to send the response back to the CBG 10 through anSMS. In either case, the CBG 10 receives the response and validates theuser.

The SIM application can be part of the CBG platform and service and isdelivered to the phone using standard SMS mechanisms defined in the GSMstandard. The SIM API Toolkit in the GSM standard defines mechanisms todevelop such applications and send them to the phone. The SIMapplication contains a way to receive the token input from the phone'skeypad, an algorithm to compute the response, a mechanism to display theresult or to send the response as an SMS back to the CBG.

This approach is secure since only those phones that are provisioned forthe service have this application on them. Further, there is no easy wayto get access to the response generation algorithm on the phone. Inaddition, USSD is supported on all phones.

A fourth possible approach involves using the phone 30 as anauthenticator as illustrated, e.g., in FIG. 7. In this scheme, the usermerely sends a USSD message to the CBG 10 after having entered the loginand password. This verifies that the user is in possession of the phone30. Passwords are not sent across to and from the terminal 32 and phone30. While relatively simple, this method still ensures authenticity bymaking the user proactively send an acknowledgement to the CBG 10. Allthis needs on the phone side is the ability to send either amobile-originated SMS or a USSD message.

Advantages of this approach include ease of use. In addition, use ofUSSD supports roaming users.

Some of the phone-SIM authentication schemes involve USSD-basedintegration as illustrated in FIG. 8. The USSD message from the phone issent to the HLR 12. The message can be of the type *serviceID*information*. The service ID specifies the identification for thespecific USSD application. This can be used by the USSD server 36 todetermine which USSD application server to forward the request to. Inthis case, the USSD server 36 sends the data to the CBG 10. The secondparameter contains the actual information sent by the user's phone 30.This is sent from the USSD server to the USSD application as an IPmessage. The USSD server 36 also sends the IMSI of the phone to the USSDapplication on the CBG 10.

Authentication Integration With Hotspot Architecture

CBG interaction with other authentication systems at the hotspotlocation is now further described. The hotspot typically has its ownauthentication infrastructure in place. The CBG is designed to operatewith this infrastructure. Most hotspots use a RADIUS server to provideauthentication of its users. The RADIUS setup includes two maincomponents: a network access server such as a router at a hotspot and aRADIUS server either at the hotspot or on the Internet. The networkaccess server functions as a RADIUS client.

The authentication process at a RADIUS-enabled hotspot independent ofthe CBG is described first. This is followed by a discussion of how theCBG fits into such an architecture.

RADIUS Operation

A user comes to a hotspot and starts accessing the Internet through hislaptop. The access server at the hotspot, such as, e.g., a Cisco Routeror a Nokia Access controller intercepts the session and sends apre-defined web page to the user. This typically queries the user for alogin and a password. The user sends this information to the accessserver. The access server functions as a RADIUS client. This RADIUSclient in turn contacts a RADIUS server located within the network. TheRADIUS client sends an Access Request message to the RADIUS server. Themessage contains the login and password with appropriate encryption. TheRADIUS server in turn compares the received password with theinformation in its local database. Once authenticated, the RADIUS serverresponds with an Access Response to the RADIUS client.

Integration of CBG with RADIUS

This hotspot configuration can be extended to support users connectingto the CBG. In this case, the users connecting at the hotspot arepresented with a selection of their ‘domain’. For instance, users mayselect between ATT and VERIZON as possible authentication domains. Thismechanism uses the realm or network access identifier concept of theRADIUS protocol. The user specifies the login and password, in additionto the domain. This information is passed from the RADIUS client to theRADIUS server. The RADIUS server, in turn, looks up its configurationsetup to determine how to authenticate users for different domains. TheCBGs, installed at the operator premises, typically provide thisauthentication for those users. The RADIUS server then forwards theauthentication request to the appropriate CBG. In this case, the RADIUSserver acts as a forwarding proxy and the CBG functions as a remoteRADIUS server. The CBG receives the authentication request from theRADIUS server as a RADIUS message. The CBG in turn, authenticates theuser by checking its local database. Also, in some cases the CBG may dothe additional SIM check or the phone check to get authenticationinformation. Once the user is authenticated, the CBG sends an AccessResponse to the RADIUS client through the RADIUS server and the user isthen authenticated. FIG. 9 illustrates this mechanism. The request froma user terminal 50 goes to the hotspot network access server 52. Thisaccess request is then sent to the RADIUS server 54 as user@domain. Inthis example, the user's login is 212-555-1212 and the domain isvzw.com. When the request arrives at the hotspot RADIUS server, itdetermines the appropriate CBG 10 to send the request to based on thedomain—an ATT user's request is forwarded to the CBG at the ATTlocation. The CBG 10 is identified through a publicly accessible IPaddress or domain name. The CBG 10 and the hotspot RADIUS server 54 alsomaintain their shared secret keys for sending the password and otherencrypted information.

As discussed previously, the CBG may do a second level ofauthentication. For example, in the SIM-enabled terminal scenario, theCBG will retrieve the vector of {RAND, SRES} for this user from the HLR.The CBG will send the RAND challenge to the user's terminal. The SIM onthe terminal computes the response and returns the response to the CBG.The CBG compares the received response SRES with the expected response.If the two match, then the CBG enables the user in the second level ofauthentication. In this case, the CBG acts as a VLR accessing the HLR.

Similarly, in the case where the user's phone is used forauthentication, the token server in the CBG generates the unique tokenand communicates with the user through one of the four mechanismsdiscussed previously. After the user is validated, the second level ofservices is enabled for the user.

Note that if no RADIUS server is associated with the hotspot, then theCBG can provide the complete authentication as well by functioning asthe RADIUS server. In this case, the CBG can provide support foradditional operators through the realm concept described further below.

This architecture is scalable and can support multiple operators servinga single hotspot through the realm concept.

The CBG server 10 can include the following components:

(a) A RADIUS server module to interface with the hotspot RADIUS systems.Note that other schemes such as, e.g., TACACS and DIAMETER can also besimilarly supported.

(b) A user database that stores the user profiles and password.

(c) A VLR proxy that connects to the HLR over a SS7 link. This can beused to fetch the authentication vectors for SIM-based authentication.

(d) A token server, which sends the password tokens to the user's phone.This may also interface with a USSD server as described earlier.

Billing Integration

Billing integration is now described, particularly the approach by whichthe CBG leverages existing hotspot infrastructure to collect accountinginformation and converts it to a format that can be passed to the WANoperator billing system.

The RADIUS protocol provides a method to collect accounting information.The RADIUS client sends an Accounting Request to the RADIUS server atthe beginning and end of the user session. This request passesinformation regarding the volume of data sent and the duration of thesession.

The CBG can function as a remote RADIUS server, and the local RADIUSserver sends the accounting messages over to the CBG. The CBG thenprocesses this information and generates accounting information in aform suitable for WAN billing systems. FIG. 10 illustrates this billingintegration system. The RADIUS client at the hotspot sends an Accountingmessage to the RADIUS server 54, which forwards it to the remote CBG 10.As shown, this message includes information such as the number of bytessent on the input and output interfaces as well as the duration of thesession.

The CBG billing components can include:

(a) A RADIUS server that receives this accounting information.

(b) An accounting module that converts this information to anappropriate format.

(c) An accounting database that stores accounting information.

The CBG interfaces with the operator billing systems in one of severalways, including the following:

(a) The CBG generates GPRS-compatible usage information. This is sent toa GPRS charging gateway, similar to other GPRS elements such as the SGSNand GGSN. This enables the operator to leverage its existing GPRSinfrastructure to generate the integrated bill. Further details of thissystem will be described below in connection with FIG. 11.

(b) Alternately, the CBG may generate charging information in a standardformat, such as IPDR. In this case, operator's existing billing ormediation systems can collect this IPDR information as if they werecollecting it from other network elements.

(c) The CBG may also generate usage information in flat comma separatedfiles or XML files that can be formatted to connect to generally anybilling system. For example, a billing system by Portal can accept usageinformation in a flat file and send it to the final operator systems.

(d) The CBG may also generate TAP3 compatible records that are typicallyused for GSM roaming.

The CBG itself preferably does not generate any billing information. TheCBG collects usage information and couples to the operator's existingbilling entities that use this usage information to generate the finalbill. The actual rating is done by the operator's existing systems.

FIG. 11 illustrates the integration of the CBG 10 with the GPRS billingsystem 61. As mentioned earlier, the SGSN 60 and GGSN 62 within the GPRSnetwork typically generate usage information using the GTP' protocol, asdefined by the GPRS standard 12.15. The CBG 10 is designed to functionas another GPRS network element, from the GPRS network point of view. Asshown in FIG. 11, the CBG 10 collects RADIUS accounting information andconverts it to the GPRS format. The figure shows the main usageparameters collected and generated. The connection between the CBG 10and the charging gateway 64 is typically IP. The charging informationsent over the GTP' protocol is sent over UDP, as defined by thestandard.

The GPRS billing format supports different charging records generatedwithin the SGSN and the GGSN. Table 1, which follows, shows variousdifferent parameters in the GPRS charging records and the correspondinginformation that can be collected for the CBG. The G-CDR indicates themetrics collected by the GGSN and S-CDR indicates metrics collected bythe SGSN. The right-most column indicates the corresponding informationgenerated by the CBG. Note that if the field is blank, it is not used.The letters M, C, and O, are mandatory, conditional and optional,respectively. Fields italicized are also in the S-CDR. Underlined fieldsare used in the CBG. Of interest is the field Node ID in the G-CDR. Thiscan be used to specify that the usage information was collected by theCBG. This information can be used by the operator's billing systems toapply a different policy to LAN usage, if desired. Field Description CBGUsage Record Type M GPRS GGSN PDP context record. G-CDR type Networkinitiated PDP C Present if this is a network initiated PDP contextcontext. Anonymous Access Indicator C Set to true to indicate anonymousaccess (and that the Served IMSI is not supplied). Served IMSI M IMSI ofthe served party (if Anonymous Access IMSI Indicator is FALSE or notsupplied). GGSN Address M The IP address of the GGSN used. RouterAddress Charging ID M PDP context identifier used to identify this PDP Aunique ID created by the CBG context in different records created byGSNs SGSN Address M List of SGSN addresses used during this record. Thisis an ASN.1 SEQUENCE. Access Point Name Network M The logical name ofthe connected access point e.g., providername.com Identifier to theexternal packet data network (network identifier part of APN). APNSelection Mode O An index indicating how the APN was selected. PDP TypeM PDP type, e.g. X.25, IP, PPP, or IHOSS:OSP IP Served PDP Address M PDPaddress, e.g. an IPv4, IPv6 or X.121. IP Address assigned to WLANendpoint Remote PDP Address O List of PDP addresses of the remote hostor DTE e.g. an IPv4, IPv6, or X.121 (Included if the PDP type is X.25)Dynamic Address Flag C Indicates whether served PDP address is dynamic,i.e., allocated during PDP context activation. List of Traffic DataVolumes M A list of changes in charging conditions for this This is theactual octet counts PDP context, each time stamped. Charging for bothdirections. conditions are used to categorise traffic volumes, such asper tariff period. Initial and subsequently changed QoS andcorresponding data values are listed. Data volumes are in octets abovethe GTP layer and are separated for uplink and downlink traffic. RecordOpening Time M Time stamp when this record was opened. TimestampDuration M Duration of this record in the GGSN. Duration Cause forRecord Closing M The reason for the release of record from this PDPContext Release (same as GGSN. logoff) Diagnostics O A more detailedreason for the release of the connection. Record Sequence Number CPartial record sequence number, only present in Might use this case ofpartial records. Node ID O Name of the recording entity. This fieldcontains an optional operator configurable identifier string for thenode which generated the CDR Used to identify CBG Record Extensions O Aset of network/manufacturer specific extensions to the record. LocalRecord Sequence O Consecutive record number created by this Number node.The number is allocated sequentially including all CDR types. RecordType M GPRS SGSN PDP context record. S-CDR type Network Initiated PDP CPresent if this is a network initiated PDP context. Context AnonymousAccess C Set to true to indicate anonymous access (and Indicator thatthe Served IMSI is not supplied) Served IMSI M IMSI of the served party(if Anonymous Access IMSI Indicator is FALSE or not supplied). ServedIMEI C The IMEI of the ME, if available. SGSN Address M The IP addressof the current SGSN. MS Network Capability O The mobile station NetworkCapability. Routing Area O Routing Area at the time of the recordcreation. Could use an unused routing area code and location area codeto specify CBG Local Area Code O Location area code at the time of therecord Could use an unused routing creation. area code and location areacode to specify CBG Cell Identity O Cell id at the time of the recordcreation. Charging ID M PDP context identifier used to identify this PDPA unique ID created by the context in different records created by GSNsCBG GGSN Address Used M The IP address of the GGSN currently used. TheCould use the router address GGSN address is always the same for anactivated PDP. Access Point Name M The logical name of the connectedaccess point e.g., providername.com, see Network Identifier to theexternal packet data network (network GSM 03.03 identifier part of APN).APN Selection Mode O An index indicating how the APN was selected. PDPType M PDP type, e.g. X.25, IP, PPP, IHOSS:OSP IP Served PDP Address MPDP address of the served IMSI, e.g. an IPv4, IP Address assigned toWLAN IPv6 or X.121. endpoint List of Traffic Data M A list of changes incharging conditions for this This is the actual octet counts Volumes PDPcontext, each time stamped. Charging for both directions. conditions areused to categorise traffic volumes, such as per QoS/tariff period.Initial and subsequently changed QoS and corresponding data values arelisted. Data volumes are in Octets above the SNDCP layer and areseparated for uplink and downlink traffic. Record Opening Time M Timestamp when PDP context activation is Time created in this SGSN or recordopening time on following partial records Duration M Duration of thisrecord in the SGSN. Duration SGSN Change C Present if this is firstrecord after SGSN change. Cause for Record Closing M The reason for therelease of record from this PDP Context Release (same as SGSN. logoff)Diagnostics O A more detailed reason for the release of the connection.Record Sequence Number C Partial record sequence number in this SGSN.Might use this Only present in case of partial records. Node ID O Nameof the recording entity This field contains an optional operatorconfigurable identifier string for the node which generated the CDR. Canuse this to identify CBG Record Extensions O A set ofnetwork/manufacturer specific extensions to the record. Local RecordSequence O Consecutive record number created by this node. Number Thenumber is allocated sequentially including all CDR types. Access PointName M The Operator Identifier part of the APN. See GSM 03.03 OperatorIdentifier

Security

The security mechanisms supported in the CBG 10 are illustrated in FIG.12. The login/password exchanged between the laptop 32 and a hotspot‘AAA’ server 70 (which manages authentication, authorization andaccounting functions, e.g., a RADIUS server) can use MD5 encryption. Theshared secret between the CBG and the AAA server is set up by thehotspot operator and the wireless WAN operator. For other exchanges suchas the typed password between the laptop and the CBG, SSL encryption isused. The SMS or USSD messages use the encryption mechanisms within theGPRS/GSM infrastructure. Further, the AAA server and the CBG mayexchange information through an encrypted tunnel using IPSec, forexample. The AAA server and CBG can also be setup for mutualauthentication through certificates to avoid rogue devices.

Shared Hotspot Support

Since the 802.11 spectrum is in the unlicensed band, it is likely thatmultiple operators would want to share a given deployment at a hotspotto support their users. There are several business models in thisscenario. One possibility is where one operator deploys and maintainsthe hotspot equipment and the other establishes the roaming agreement.Another possibility is one where a neutral systems integrator maintainsthis hotspot and none of the operators actually owns the equipment atthe hotspot. Different business models apply in these different cases.

The CBG supports multiple business models and allows the users to roamacross different 802.11 islands. The CBG uses the mechanisms within theRADIUS protocol to provide this roaming support. This also makes itpossible to support multiple operators within a given hotspot location.

FIG. 13 illustrates the system architecture for a typical hotspotdeployment that supports multiple operators. Suppose that operator 1 andoperator 2 provide service within the hotspot. The RADIUS server 72presents the operators' options for the realm selection at the hotspot.Depending on the selected realm, the RADIUS server 72 contacts theappropriate CBG 10.

Another aspect of the unlicensed spectrum is that if multiple operatorsdeployed their own equipment, it could lead to interference unless thespectrum is shared effectively. In the 802.11b space at 2.4 GHz, thereare three non-overlapping channels. Thus, it is possible for threeoperators to deploy equipment within one region provided they agree onwhich channels to pick. This places a requirement on the user's terminalto be able to select the correct operator's equipment.

One way to accomplish this is outlined next. Each operator selects itschannel and assigns an ESSID (extended service set ID, as defined by the802.11b standard) to its access points (APs). Thus, all the APs owned byoperator 1 will be set to ESSID OP1 and all APs owned by operator 2would be set to ESSID OP2. Each AP broadcasts its ESSID. The clientsoftware on the user's terminal maintains a list of ‘preferred’ networkID's (similar to preferred roaming partners stored in the SIM card forthe GSM roaming network). The client when associating with a given APwould use this information.

CBG Components

A typical architecture of the CBG is now described in further detail. Asmentioned earlier, the CBG comprises two key components: the client andthe server.

CBG Server

FIG. 14 illustrates the main components of the CBG server 10. The CBGserver is preferably hosted in the operator's network.

The RADIUS server module 80 implements a standard RADIUS protocol andinterfaces with the RADIUS server in the hotspot network. It can alsoimplement other protocols such as DIAMETER.

The Service interface module 82 is responsible for providing theinterface that manages run-time login for users. This module queries theuser for authentication information, receives the encrypted information,queries the appropriate database or the HLR proxy 84 to verify theauthentication, and enables service.

The HLR proxy module 84 is responsible for generating the authenticationinformation. This module interfaces with the HLR to get theauthentication information. The accounting module 86 is responsible forcollecting usage information from the CBG client and generating anappropriate format that the operator's billing and mediation systems canprocess.

The management module 88 presents the management interface for theoperator. It allows the different CBG components to be controlledremotely. Typical interfaces would be SNMP and HTTP.

The user database module 90 is the local CBG database that contains userspecific information. This module also provides a mechanism foroperators to introduce special policies and service-specific features.

The accounting database module 90 collects the usage informationgenerated by the accounting module. It provides an interface for theoperator's systems to collect this information. Typical interfaces canbe FTP and FTAM.

The token server module is responsible for sending out thetoken/password through SMS or USSD, as described previously.

CBG Client

The CBG client is an optional module, and is used generally only whenthe user's terminal has a SIM reader or SIM card. It can also beoptionally used to measure usage information.

Hotspot LAN Configurations

Typical configurations of hotspot locations from which the user mayaccess data are described below.

Hotspot with a Building Broadband Service Manager

A typical hotspot such as an airport typically has several 802.11baccess points 101. These access points are connected through a router tothe public Internet. Typical access control equipment is the BuildingBroadband Service Manager (BBSM) available from Cisco. (FIG. 15 shows atypical hotspot with the BBSM 100.) This allows the hotspot operator toblock access to the router 102 until the user has been authenticated.Specifically, the BBSM 100 presents the user with login request; therequest is passed to an authentication server over a protocol likeRADIUS. The authentication server may be located at the hotspot itselfor anywhere else on the public Internet. When the authentication requestis granted, the BBSM 100 informs the router 102 to allow the traffic togo through.

A BBSM-enabled hotspot can be modified to support CBG-based WANauthentication by the addition of a simple script to the BBSM. Thisscript allows WAN-user requests to be forwarded to the appropriate CBG,depending on the carrier that the user belongs to. When authenticationrequests come to BBSM, it asks the user to select the WAN operator andpasses the request to the appropriate CBG.

Coffee Shop Subscribing To A Wireless ISP Roaming Service

Another popular method of providing 802.11 service is by deploying APsat smaller areas such as, e.g., coffee shops. In this case, typicallyone or two APs 101 are deployed at a coffee shop. To provide accesscontrol, the WISP maintains authentication centers within its backbone,since it is not economical to deploy access control at each physicallocation. Typical equipment used includes, e.g., the Nokia public accesszone controller. When a subscriber tries to start accessing theInternet, the request is blocked until he is authenticated. Theauthentication request goes to the access controller. The accesscontroller presents the subscriber with a login request. The user'sresponse is sent to its authentication database. Once authenticated, theuser is allowed to start using the service.

One design issue is related to supporting multiple operators within agiven hotspot. Since the 802.11b network uses unlicensed spectrum, it isnot possible for multiple operators to provide their own infrastructurein a given region due to interference. This leads to a natural accessingsharing architecture, where one entity deploys the infrastructure andothers share it.

To address this access sharing issue, wireless ISPs are setting up awireless ISP roaming initiative (WISPR) that allows ISPs to offerroaming services. In this case, a user who is a subscriber of adifferent WISP can access the Internet from a foreign ISP's network andget charged roaming fees. To implement this, the user comes to a foreignWISP network and tries to access the network. The user is queried forlogin information regarding his home ‘realm’. The access controllercontacts the appropriate home authentication center to authenticate theuser. Subsequently, the two ISPs settle charges for roaming users.

FIG. 16 shows a typical configuration of a hotspot setting using awireless roaming arrangement and deploying an access controller 110 inthe network.

A WISPR-enabled hotspot can be modified to support CBG-based WANauthentication by the addition of a simple script to the WISP accesscontroller. This script allows WAN-user requests to be forwarded to theappropriate CBG, depending on the carrier that the user belongs to. Sothe access controller asks the user to select the WAN operator andpasses the request to the appropriate CBG.

Hotspot Enabled With iPass Roaming Service

Another popular way of deploying wireless LAN access is through the useof a clearinghouse like iPass or GRIC. In this case, the hotspotcontains one or more access points 101 that are connected to theInternet through a router 113. Authentication is now managed through theclearinghouse. This allows multiple ISPs to share a singleinfrastructure and yet provide different services to their users.

Typically, the subscriber has an account with iPass. IPass, in turn,negotiates multiple partnerships with different enterprises as well aswith different hotspot operators and ISPs. IPass deploys a networkaccess server at the hotspot location. The network access server sendsall authentication requests to an iPass transaction center. Thetransaction center looks at the user's login and determines who theauthentication entity is. The authentication request is sent to theiPass Roam Server 111 in the appropriate enterprise. This communicateswith the enterprise authentication servers. The user is authenticatedand the request is allowed to go through. The network server andtransaction center keep track of each user's usage and generate theappropriate bills.

FIG. 17 shows a typical configuration using iPass 112. The use of a BBSM100 is optional in such a setting.

An iPass-enabled hotspot can be modified to support CBG-based WANauthentication by the addition of a simple script to the iPasstransaction center. This script allows WAN-user requests to be forwardedto the appropriate CBG, depending on the carrier that the user belongsto. So the CBG is another authentication center from the view of theiPass transaction center. An iPass roam server is deployed at the CBG toprovide any desired protocol conversion between iPass and standardradius protocols.

Kiosk-based Internet Access

Another popular method of providing Internet access at public hotspotsis through Internet kiosks. FIG. 18 shows a typical kiosk system 116. Inthis case, the user is not required to take his terminal, but can useexisting terminals deployed at the public locations. In this setting,the kiosk operator connects the kiosks to an access controller, whichthen allows Internet access. The access controller requestsaccount/credit card information from the user. It contacts theappropriate accounting entity to charge the user. The BBSM 100 describedearlier is one such access control device.

A kiosk-based hotspot can be modified to support CBG-based WANauthentication by the addition of a simple script to the controller inthe kiosk. This script allows the kiosk to query for WAN-based users.The WAN-user requests are forwarded to the appropriate CBG, depending onthe carrier that the user belongs to.

802.1X Support

For 802.1x support, the access server is not required. In this case, the802.1x enabled access point blocks user access and has the embeddedRADIUS client that exchanges authentication information with theCBG/RADIUS server.

Service Signup Call Flows

Call flows are now described for different service signup scenarios forthe first authentication mechanism where the operator database is usedto login and the LAN login/password is used for service usage. Note thatthe WAN subscriber can sign up for LAN service from various places suchas, e.g., from home, from an airport, or from a coffee shop. Theseaccess mechanisms can be different and require different call flows.

The system architecture of the CBG and the CBG client do not change inany of these cases. Note also that these are specific non-limitingexamples to illustrate how the CBG supports different scenarios.

As mentioned earlier, the service signup call flow is typically executedonly once for each user during subscription sign up.

In the first signup scenario, the user signs up for WAN services fromhis terminal using an existing Internet access mechanism such as, e.g.,from home or work. It is assumed the user has a LAN-only NIC, without aSIM or other WAN features. The call flow is summarized below and in FIG.19:

1. The user subscribes to carrier-certified LAN access service by goingto a carrier web site through existing Internet access such as from homeor work. The request is forwarded to the CBG server 10.

2. The service provisioning module in CBG server 10 gets ID informationfrom the user and validates user's identity by checking against theoperator's database (similar to adding other WAN services).

3. The user creates a password associated with a login such as a phonenumber.

4. This information is stored in local database associated with CBGserver 10.

5. The CBG downloads CBG client on the terminal (client contains someoperator-specific service attributes as well as usage instrumentationutility).

In a second signup scenario, the user goes to a public hotspot such asan airport that deploys a BBSM 100. The BBSM has been modified by theCBG script. The user has his own terminal with him. The terminal isassumed to have a LAN-based NIC such as an 802.11 card and does not haveany WAN-specific features such as a SIM. The call flow is summarizedbelow and in FIG. 20:

1. The user goes to hotspot with laptop and sees signs forcarrier-certified LAN access.

2. The user goes to a signup web site. The BBSM script provides signuppage with carrier option (This script is a set of configurationparameters provided by the CBG).

3. The user provides information about the operator he subscribes to.

4. The BBSM 100 determines which CBG server 10 to go to (depending onoperator selected) and allows authentication exchange with the CBG.

5. The CBG Service provisioning module requests identificationinformation from the user (such as, e.g., address and social securitydigits) and validates the user's identity by checking against HLR 12(similar to adding other WAN services).

6. Once validated, the user creates a password associated with a loginsuch as a phone number.

7. This information is stored in local database associated with the CBGserver 10.

8. The CBG server 10 downloads CBG client on the terminal withattributes stored, such as operator's name as well as instrumentationcode.

9. The BBSM 100 directs other non-WAN user requests to other AAAdevices.

In a third signup scenario, the user goes to a public hotspot such as acoffee shop. Suppose that the coffee shop implements wireless roaming(WISPR) support. (WISPR is a consortium defining roaming protocols.) Theuser uses his terminal and has a LAN-based interface card without WANsupport. The call flow is summarized below and in FIG. 21:

1. The user goes to coffee shop with laptop and sees signs forcarrier-certified LAN access.

2. The WISP access controller 120 allows service selection through a webpage.

3. All authentication requests are directed to the access controller.

4. The user responds with WAN access request.

5. The service request is forwarded to appropriate CBG server 10 andauthentication traffic is allowed to go through to CBG server 10.

6. The service provisioning module in CBG server requests identificationinformation and validates user's identity by checking identity of useragainst database (similar to adding WAN other services).

7. After validation, the user creates a password associated with a loginsuch as a phone number.

8. This information is stored in the local database associated with theCBG server.

9. The CBG server 10 downloads CBG client on the terminal withattributes stored, such as operator's name.

In a fourth signup scenario, the user goes to a hotspot that uses iPassas a clearinghouse. The user takes his terminal that is assumed to havea LAN-based interface without any WAN support. The iPass transactioncenter is assumed to have been modified with CBG support.

Typical operation with iPass is as follows:

1. The user signs up for iPass and downloads iPassConnect client.

2. The user comes to hotspot and runs client and enters login/passwordor other way of authentication.

3. The network access server at the hotspot passes on the encryptedinformation to a transaction center.

4. The transaction center contacts the associated RoamServer toauthenticate with corporation's database, which then allows trafficthrough.

If iPass is in place, for some select users, the iPass transactioncenter 112 contacts the CBG server 10. The call flow with iPass issummarized below and in FIG. 22:

1. The user goes to hotspot, requests to signup.

2. The user selects WAN as the connection.

3. The request from transaction center is routed to appropriate the CBGserver 10 using configuration information in the script.

4. The CBG server 10 gets the user identification information as before,validates the user, and creates account.

5. The user information is stored in local CBG server database 14.

6. The CBG server downloads CBG client on terminal.

In a fifth signup scenario, the user goes to a public access terminal,such as a kiosk. The kiosk is modified to support the CBG. The call flowis summarized below and in FIG. 23:

1. The user comes to airport and sees sign for service and goes to thekiosk and to a web site 122 to create an account.

2. The kiosk 116 has a CBG script that checks which operator the userbelongs to.

3. The kiosk 116 contacts appropriate CBG server 10 to continue withservice.

4. The CBG service provisioning module gets the user's identificationinformation and validates user's identity by checking identity of useragainst database (similar to adding other services).

5. The user creates a password associated with a login such as a phonenumber.

6. This information is stored in local database associated with CBGserver. (The kiosk terminal already has a CBG client on it so there isno client download.)

Signup call flows are now described for the case when the user has aSIM-enabled terminal such as the SIM-enabled 802.11 NIC card. The usermay request sign up from any one of the five settings described earlier.The call flow related to SIM authentication is described below and inFIG. 24:

1. The user subscribes to carrier-certified LAN access service in any ofthe previous methods.

2. The service provisioning module in CBG server 10 has option tospecify whether or not there is SIM enabled terminal.

3. If yes, then a basic reader is downloaded on the terminal.

4. The service provisioning module validates terminal identity bygetting challenge/response pair from HLR and comparing challenge withuser's response.

5. The user creates a password associated with phone number as login asan additional login mechanism in case the user desires to access hisaccount without a SIM-enabled terminal.

6. This information is stored in local database associated with CBGserver 10 as in previous case.

7. The operator also downloads CBG client with attributes such asoperator's name and instrumentation utility.

Service signup for the two factor authentication mechanism is nowdescribed. The service signup for this mechanism is quite similar to theones described in the previous section with the exception that the phoneis used in addition for authenticating the user. The call flow for asample scenario for the user signing up for service from home or officeis described below with reference to FIG. 25.

1. The user subscribes to a carrier-certified LAN access service bygoing to carrier web site, through existing Internet access.

2. The service provisioning module in the CBG 10 validates the user'sidentity by checking against the operator's database.

3. The user creates a password associated with a login such as a phonenumber.

4. This information is stored in local database associated with the CBG10.

5. The CBG 10 verifies that the user is in possession of a phone byusing one of the mechanisms described earlier.

FIG. 26 and the call flow below illustrate an example of service signupfrom a RADIUS-enabled hotspot using the BBSM 100. This generally appliesto most of the other RADIUS based setups described earlier.

1. The user goes to a hotspot with a laptop or other terminal and seessigns for carrier-certified LAN access.

2. The user goes to designated web site. The BBSM provides signup pagewith carrier options.

3. The user enters his phone number.

4. The BBSM 100 determines which CBG 10 to go to (depending on operatorselected).

5. The CBG Service provisioning module validates the user's identity bychecking the identity of the user against a database.

6. The user creates a password associated with a login such as the phonenumber.

7. This information is stored in a local database associated with theCBG 10.

8. The CBG verifies that the user is in possession of a phone by usingone of the mechanisms described earlier.

9. The BBSM 100 directs other requests to other AAA devices.

Service signup for 802.1x enabled-user is now described. As mentionedpreviously, the service signup for this case is similar to the signupfor the non-SIM enabled case for all the scenarios. The only differenceis that the user might have to download a 802.1x client if he does nothave support for 802.1x. Also, for some cases, the user might beassigned a certificate.

Service Usage Call Flows

Call flows are now described demonstrating how a subscriber starts usingservice once he has created an account. The call flows described in theprevious section relate to actual creation of the service and areordinarily executed only the first time the user signs up for service.During subsequent usage, service usage call flows described below areused generally every time the user uses service.

Service Usage From Hotspot With BBSM

In this setting, the user goes to a hotspot with his terminal. The CBGclient has already been downloaded on the terminal and the terminal doesnot have any WAN capabilities like the SIM. The call flow is summarizedbelow with reference to FIG. 27.

1. The user goes to a hotspot with a laptop and starts accessingInternet traffic.

2. The BBSM 100 provides a login page with carrier option. (This scriptis a set of configuration parameters provided by the CBG.)

3. The user enters a selected operator.

4. The BBSM 100 contacts the corresponding CBG server 10.

5. The CBG service usage module validates the user's identity bychecking the identity of user against database.

6. The CBG server 10 validates user and asks client to start collectingusage information.

7. The user starts accessing the Internet.

8. The usage information is periodically transferred to the CBG server10.

9. The CBG server sends the usage information to an Accounting server131.

10. The Billing/Mediation systems can then retrieve usage information.

The CBG server preferably checks the client version after login andupdates it if necessary to get latest version. This also addresses thecase that the user may have created an account from a kiosk, but neveractually downloaded the client since he did not have his own terminal atthat time.

Service Usage From Coffee Shop

In this scenario, the user goes to a WISPR enabled location such as acoffee shop and starts using the service. The user has created anaccount previously and the client has been downloaded on the terminal.The terminal does not have SIM capabilities. The call flow is summarizedbelow and in FIG. 28.

1. The user goes to the coffee shop with a laptop or other terminal andsees signs for carrier-certified LAN access.

2. The user starts accessing the Internet.

3. The router forwards an authentication request to the WISP accesscontroller 120.

4. The WISP access controller configuration script determines theappropriate CBG server 10 to contact.

5. The CBG service usage module validates the user's identity bychecking the identity of user against a database 6. The CBG server 10validates the user and asks the client to start collecting usageinformation.

7. The user starts accessing Internet.

8. Usage information is periodically transferred from the client to CBGserver.

9. The CBG server 10 sends the usage information to the Accountingserver 131.

10. The Billing/Mediation systems can then retrieve the usageinformation.

Service Usage From Hotspot With iPass

In this scenario the user accesses the service from a hotspot that hasbeen enabled with iPass. The user's terminal has downloaded the clientand does not have SIM capabilities. The call flow is summarized belowand in FIG. 29.

1. The user goes to the hotspot, and tries to start accessing data.

2. An authentication request is sent to the iPass transaction center112.

3. The user specifies WAN as the connection type.

4. The configuration script in the transaction center determines theappropriate CBG server 10.

5. The CBG service usage module gets identification information from theuser and matches it with its local database. The CBG server validatesthe user and asks the client to start collecting usage information.

6. The CBG client collects usage information and sends it to CBG server10 periodically. The CBG server 10 generates usage records that can beaccessed by the carrier billing and mediation systems.

Service Usage From Kiosk

In this scenario, the user accesses the service from a kiosk. The useris assumed to have already created an account. The call flow issummarized below and in FIG. 30.

1. The user comes kiosk 116 and starts accessing the Internet.

2. The kiosk configuration script starts the login procedure.

3. The kiosk 116 contacts the appropriate CBG server 10 to continue withservice.

4. The CBG service usage module validates the user's identity bychecking identity of user against database.

5. The CBG 10 validates the user and asks client to start collectingusage information.

6. The user starts accessing Internet.

7. Usage information is periodically transferred to the CBG server 10.

8. The CBG server sends usage information to the Accounting server 131.

9. The Billing/Mediation systems can then retrieve usage information.

Service Usage With SIM-Enabled NIC

This section describes the call flow when the user is using the servicewith a SIM-enabled NIC. The access method can be any one of the fourmethods described earlier. The call flow is summarized below and in FIG.31.

1. The user starts accessing data from one of the methods previouslydescribed.

2. The CBG service usage module has option to specify whether or notthere is SIM enabled terminal.

3. If yes, the service usage module validates the terminal identity bygetting a challenge/response pair from HLR and comparing challenge withthe user's response.

4. The user starts accessing the Internet.

5. Usage information is periodically transferred to CBG server 10.

6. The CBG server 10 sends the usage information to the Accountingserver 131.

7. The Billing/Mediation systems can then retrieve usage information.

Service Usage For Two-Factor Authentication

Call flows are illustrated below for the scenario where the user's phoneis used for a strong authentication.

FIG. 32 illustrates an example call flow for service usage from aBBSM/router enabled hotspot.

1. The user goes to hotspot with his laptop or other terminal and startsaccessing Internet traffic.

2. The BBSM 100 provides a login page with carrier option.

3. The user enters his phone number and selects the realm.

4. The BBSM RADIUS client contacts the appropriate CBG.

5. The CBG RADIUS module receives the login and password and comparesagainst internal database.

6. The CBG Token server establishes authentication with the user'sphone.

7. The CBG validates the user.

8. The user starts accessing Internet.

9. Usage information is sent from router/radius client to CBG at end ofthe user session.

10. The CBG sends the usage information to the Accounting server.

11. The Billing/Mediation systems retrieve the usage information.

FIG. 33 illustrates an example call flow for service usage from an iPassenabled hotspot.

1. The user goes to the hotspot, and starts accessing data. The terminalhas an iPass client.

2. The user specifies NAI (Network access identifier) as part of theconnection.

3. The configuration script in transaction center determines appropriateCBG 10.

4. The request from transaction center is routed to the appropriate CBG.

5. The CBG 10 matches the phone number with its database to authenticatethe user.

6. The CBG 10 verifies the user through possession of phone.

7. The CBG 10 verifies the user.

8. The CBG 10 receives usage information at the end of the user session.

9. The CBG 10 generates accounting information to be collected by thebilling/mediation systems.

Service Usage for 802.1x System

The service usage for 802.1x follows a sequence similar to the non-SIMcase, with the exception that the user does not have to be interceptedthrough the web browser.

1. The user fires up terminal and starts 802.11 NIC.

2. The access point blocks traffic and queries the user forauthentication.

3. The user sends either the login/password or certificateauthentication using 802.1x.

4. The CBG verifies the user.

5. The user starts accessing Internet.

6. Usage information is periodically transferred to the CBG server 10.

7. The CBG server sends the usage information to the Accounting server131.

8. The Billing/Mediation systems can then retrieve usage information.

CBG Implementation

By way of example, the CBG can be implemented using the followingcomponents.

The CBG server can be a carrier-class system that is built on aSun/Solaris platform. In one embodiment, the HLR interface is designedto use a Trillium stack and GSM MAP software. The AAA interface can bethrough RADIUS or DIAMETER. The database modules can be implemented onan Oracle real-time database. The database can also be accessed througha LDAP interface.

The CBG client can be a piece of software that is implemented on popularend-user platforms, such as Windows 2000, Windows 98, Pocket PC, SymbianOS, and Palm OS. The CBG server downloads the client code. The clientcode communicates with the device drivers in the network interface tocompute usage. It also preferably includes encryption mechanisms to sendauthentication and usage information to the CBG.

Typical encryption schemes such as 128 b SSL can be used.

CBG Architecture Features

The CBG in accordance with various embodiments of the invention has anumber of advantageous features including the following.

First, the CBG is not restricted to SIM-based terminals. It enables LANusers using virtually any IP based interface to be authenticated with aWAN system. It also supports LAN users with a SIM-enabled device to beauthenticated with the WAN system.

In addition, the CBG generates consistent usage information, regardlessof the access technology.

Furthermore, it has a flexible architecture that works with a variety ofhotspot deployments and does not restrict the hotspot architecture.

The CBG can be used with virtually any IP based access system, includingwired as well as wireless LANs.

Also, the CBG architecture supports multiple operators within a givenhotspot.

The CBG can be used with mobile IP for integrating their authenticationwith the HLR.

Having described preferred embodiments of the present invention, itshould be apparent that modifications can be made without departing fromthe spirit and scope of the invention.

1. A method, operative in a gateway, for managing usage of a local areanetwork (LAN) by a subscriber of a wide area network (WAN), the widearea network being operated by an entity providing a telecommunicationservice that is normally accessible to the subscriber by having anexisting WAN authentication mechanism authenticate the subscriber whenthe subscriber uses the WAN to obtain the telecommunication service, theWAN having an existing WAN billing mechanism, comprising: (a)authenticating the subscriber based on authentication informationreceived from the subscriber and corresponding information of record atthe existing WAN authentication mechanism; (b) receiving information onsubscriber usage of the LAN, wherein the information on subscriber usageof the LAN is measured by one of: a client program, an existing LANmeasurement infrastructure, and a monitor deployed in the LAN; and (c)transmitting the information on subscriber usage of the LAN to theexisting WAN billing mechanism for billing by the entity of LAN and WANusage, wherein the information on subscriber usage of the LAN istransmitted using a data structure that the existing WAN billingmechanism expects to receive, wherein the data structure includes atleast one optional field that includes data identifying the gateway as asource of the information on subscriber usage of the LAN; wherein thegateway interacts with the existing WAN authentication mechanism and theexisting WAN billing mechanism, without modifications to thosemechanisms, to enable the subscriber to access, to use, and to be billedfor the subscriber usage of the LAN using the subscriber's WAN identity.2. The method as described in claim 1 wherein the at least one optionalfield is a Node ID field of a GPRS call data record.
 3. The method asdescribed in claim 1 wherein the entity providing the telecommunicationsservice applies a billing policy to the subscriber usage of the LAN thatdiffers from a billing policy applied to the subscriber's usage of theWAN.
 4. The method as described in claim 1 wherein the entity is one of:a GSM operator, a CDMA operator, and an Internet Service Provider (ISP).5. The method as described in claim 1 wherein the information of recordis associated with the subscriber's WAN identity and the informationreceived from the subscriber is one of: (i) IMSI information obtainedfrom a SIM card associated with the terminal, (ii) a user login andpassword obtained during a service provisioning, (iii) IMSI informationprovided in software executable in the terminal, (iv) IMSI informationprovided in a network server, (v) a token or one time password exchangedby the terminal through SMS, (vi) a token or one time password exchangedby the terminal through USSD, and (vii) a token or one time passwordgenerated using an application associated with a SIM card.